Compile-time scheduling with resource-constraints

Most tasks in DSP-applications require multiple resources for their execution. If only CPU-usage is considered while constructing a static schedule, the actual run-time performance of the application can differ a lot from the predicted one. In this paper we present a scheduling method that takes non-CPU resourcerequirements into account as well while constructing the static schedule. Situation of the problem. Most Digital Signal Processing (DSP) applications have to operate at very high sample-rates (order of MHz), such that static schedules are required to obtain real-time performance. Such static schedules are mostly automatically produced by CAD-tools [3], [5], [6], [7]. Most of these tools consider CPU-usage to determine a “time-optimal” task-execution order at compile-time. Once the order is fixed, code is generated and downloaded on the processor hardware for execution. During the execution of such a schedule however, it is quite possible that the actual performance differs a lot from what was predicted by the static schedule. First it is possible that the run-time makespan far exceeds the estimated one. This might be caused by wrong timingestimates for the tasks in the application. When the estimate supposes e.g. the use of internal memory to store program-code and data, while the actual task uses external memory, the real execution-time greatly exceeds the estimated one. But even if all estimates of executiontimes are accurate, the actual makespan can still differ a lot from the predicted one. This happens when multiple tasks try to access a shared device like e.g. a communication-link or a shared bus at the same time. In this case only one task gets access to the device while the others have to wait until it is released again. Such contention-delays are not counted for in a classically constructed static schedule. Besides those timing-aspects, also other surprises can arise while trying to execute the schedule. When too many tasks are assigned to the same device, the total amount of memory required can exceed the available amount. In this case we do not even succeed in downloading the code on the multi-processor board and the actual execution can never start. Another problem arises when the same hardware FIFO-buffer is used for communication between multiple tasks. When the first write-operation corresponds e.g. with the communication between two tasks A and B, while the first scheduled readoperation delivers data to a task C, the application will behave incorrectly. Resource-constraint scheduling in GRAPE-II. To avoid these problems and to guarantee that the static schedule we produced behaves as we expected, we have to take resource-requirements into account. In GRAPE-II (Graphical RApid Prototyping Environment) [l], [2], [4] this is done by representing all resourcerequirements as separate tasks that need to be assigned to the different resources. Every user-task then corresponds to a cluster of subtasks, one for each associated resourcerequirement. During assignment an entire task-cluster is assigned to a cluster of devices. The router adds communication-tasks, wherever data need to be transported. And finally in the scheduler all subtasks are ordered on their devices. To preserve the timing-relations between related subtasks, all subtasks belonging to the same task-cluster are placed together, taking into account their internal timing-relations as well as the load on the devices they have to be executed on. Depending on the nature of the resource-requirement, three types of resource-subtasks are distinguished. 153 1060-3425/95$4.00